One of the major challenges within a telecommunication network is the delivery of broadband communications over the network to specific receivers or customers in a cost-efficient, timely, and effective manner. Two endpoints may send and receive information through entities of the telecommunication network. For example, a user of a computer may communicate with another user of another computer through the network. Or, as another example, a server may communicate with a process controller through the network to receive instructions from the controller. The network may not initially know what type of communication session to establish between the two endpoints. The type of communication session depends on the type of endpoints communicating through the network. As a result, the network may begin the communication session as a default type and later decide whether the type of session should be changed.
As an example, a customer may desire to fax an order for supplies to its supplier. The customer may begin a session through the network with another facsimile machine. The network may initially establish the session as an audio session, either by a random choice or because most entities communicating through the network desire a voice communication session. And upon receiving data from the first facsimile machine, the network may then realize that this is not an audio call, and subsequently may modify the communication session to be a facsimile relay session.
In the example above, each facsimile machine probably communicates with a separate transmission entity of the network, such as a gateway. And when the network switches between types of communication sessions, it is necessary for both gateways to know what type of communication session is currently being used or what state the “other” gateway is in so that both gateways can synchronize the transmission of voice or data. Synchronization of the transmission may also be necessary since separate payload data packet types are used even if the underlying encoding is the same (e.g. voice and voiceband data encoding each may use Pulse Code Modulation μ-law (“PCMU”)). Each payload type associated with a different encoding can have a separate format; therefore, it is desirable that the two gateways comprising the communication session be in synchronization of encoding formats.
One existing method of synchronizing transmission entities of the network is through the use of the User Datagram Protocol (“UDP”), which is a packet format included in the Transmission Control Protocol (“TCP”) suite and used for short user messages and control messages. However, transmission of messages using the UDP is unacknowledged and, therefore, there is no guarantee that the messages will be received. And since data packets are frequently lost within the network, one gateway may continue transmitting information in an audio format because the gateway was never informed that the communication session has been changed to a facsimile relay session. This may cause a problem since the other gateway will be looking to receive data in the form of a facsimile relay session and, therefore, may not recognize the audio formatted data.
As an alternative to using UDP, the TCP can be used to deliver the state information. However, TCP can waste bandwidth since TCP will unnecessarily transmit all state information and will transmit data during inactive periods. For example, the two gateways only need to know the current state in order to properly transmit data. But, using TCP, all intermediate state information is included within the state information transmission. So if the gateways initially began communicating in an audio format, then switched to a Voice Band Data (“VBD”) mode for a modem communication session, and then finally switched to the proper facsimile relay session, the TCP protocol will transmit information informing the gateways of this sequence of state transitions. Therefore, much bandwidth is wasted since more than the necessary information is transmitted because TCP will even continue to deliver previous, undelivered state changes, when only the last state change is relevant. Another limitation to TCP is that TCP only transmits information when requested to do so. Presumably, if no state transition has occurred, there will not be a request to transmit state information, and no network resources will be used.
Another protocol that may be used is the Datagram Congestion Control Protocol (“DCCP”). This protocol, like UDP, trades reliability for fast transmission. However, unlike UDP (but similar to TCP), it was designed to be “friendly” to congested networks in the sense that it will not aggravate congestion. Unfortunately, this protocol is designed to implement a congestion-controlled, unreliable flow of datagrams suitable for use by applications such as streaming media or Internet games.
Other protocols or methods are also available. However, no protocol reliably transmits state information without wasting precious bandwidth. As another example, state information could be transmitted a fixed number of times hoping that at least one transmission would be successful. Of course, this method would also waste bandwidth if the first transmission was successful and it would be unknown whether any of the transmissions were successful. Consequently, a reliable protocol that uses bandwidth conservatively is desirable.